This PR runs SwiftFormat on the driver and adds it as part of our linting task.

In general, I tried to emulate our swiftlint config as much as possible so that this formatter would help us enforce existing rules rather than making up new ones. The one notable exception to that is the wrapArguments rule, which I've standardized to "before-first". I don't think there is a right answer here as to which option is better, but I do think that selecting any option for consistency is the right idea (as @Utagai said long ago). The majority of the diff from this PR is due to this rule.

e.g.

public func hello(a: Int, 
                  b: Int) throws -> Int { ... }

let a = try hello(a: 1,
                  b: 2)

becomes

public init(
    a: Int,
    b: Int
) throws { ... }

let a = try hello(
    a: 1,
    b: 2
)

In general, I found that this approach to wrapping produces far more readable and condensed code than only doing the "after-first" option, so I went with it.

Another thing to note is that this rule only applies to how we format multiline arguments; it doesn't decide when we do it.

e.g. the following will be untouched by the formatter:

public func a(a: Int, b: Int) throws -> Int { ... }

let b = a(a: 1, b: 2)

This means that not all output produced by the formatter will pass swiftlint due to line length issues, so manual line breakage may be necessary. The formatter will make sure that the way the lines are broken is fixed up, though.

Why not swift-format?
There is an official formatter being worked on by Apple called swift-format. I decided not to use it for this because it supports a very small number of rules compared to SwiftFormat. I think that long term, it may make sense to start using the official formatter once it becomes more mature.